Skip to content

Fix right-edge redraw at terminal bottom#112

Closed
rztaylor wants to merge 1 commit into
reeflective:masterfrom
rztaylor:fix/right-edge-bottom-wrap
Closed

Fix right-edge redraw at terminal bottom#112
rztaylor wants to merge 1 commit into
reeflective:masterfrom
rztaylor:fix/right-edge-bottom-wrap

Conversation

@rztaylor

Copy link
Copy Markdown
Contributor

Summary

Fix a terminal redraw edge case when editable input lands exactly on the right edge of the terminal while the prompt is already at the bottom of the screen.

In that state, terminals can keep the cursor in a pending-wrap position. The renderer was still appending clear-to-end-of-line before forcing the wrap, which could erase the edge character and make subsequent keypresses scroll or redraw incorrectly.

Changes

  • Add a PTY-backed regression test that places the prompt on the last terminal row and types across the right edge one key at a time.
  • Avoid emitting clear-to-end-of-line while the rendered input is in the terminal’s pending-wrap state.
  • Explicitly advance to the wrapped row before later redraw cursor movement.

Validation

  • Confirmed the new regression test fails before the renderer change.
  • Confirmed the new regression test passes after the renderer change.
  • Ran GOCACHE=/private/tmp/reeflective-readline-pr.DPe91Q/.cache/go-build go test ./...

@rztaylor rztaylor closed this Jun 23, 2026
@maxlandon

Copy link
Copy Markdown
Member

Why did you close ?

maxlandon added a commit that referenced this pull request Jul 5, 2026
The display refactor (b735972) copied displayLine into displayLineRefactored
for the main render path but dropped the pending-wrap handling the original
had for input landing exactly on the terminal's right edge. Since the copy is
the per-keystroke path, typing past the right edge on the bottom row erased the
edge glyph and wedged the redraw (scrolling a row per key). The two functions
otherwise drifted as identical copies — inline-suggestion work had to patch
both, and this fix had to patch only one.

Collapse them into a single displayLine used by both the main refresh path
(renderInputArea) and the transient-prompt redraw (RefreshTransient), and give
it correct right-edge handling: skip clear-to-end-of-line in the terminal's
pending-wrap state (it can erase the edge glyph), then force the wrap before
later clear/cursor-movement sequences.

Includes the PTY regression test from PR #112 by @rztaylor, which fails without
the fix (input wedges at the right edge) and passes with it.

Co-authored-by: rztaylor <rztaylor@users.noreply.github.com>
@maxlandon

Copy link
Copy Markdown
Member

For the record: this fix was valid and the bug it targets is real and still present on master — I reproduced it with your regression test (typing past the right edge on the bottom row wedges the redraw; the test times out without the fix and passes with it).

Investigating why turned up the root cause: the display refactor (b735972) copied displayLine into displayLineRefactored for the main render path but dropped the original's lineCol == 0 right-edge handling — exactly what your PR restores. The two functions had since drifted as near-duplicates.

I've revived your fix in #117, folded together with a de-duplication of the two render functions, and kept your PTY regression test with a co-author credit. Thanks for the original diagnosis and test — sorry this sat closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants